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ABSTRACT 

As  part  of  the  Advanced  Launch  System  technology  development  effort  begun  in  1989,  the  Air  Force  initiated  a 
prot’ram  to  automate,  to  the  extent  possible,  the  processing  of  NDE  data  from  the  inspection  of  solid  rocket  motors  during 
fabrication.  The  computerized  system,  called  the  Automated  NDE  Data  Evaluation  System  or  ANDES,  was  developed  under 
contract  to  Martin  Marietta,  now  Lockheed  Martin.  The  ANDES  system  is  generic  in  structure  and  is  highly  tailorable.  The 
system  can  be  configured  to  process  digital  or  digitized  data  from  any  source,  to  process  data  from  a  single  or  from  multiple 
acquisition  systems,  and  to  function  as  a  single  stand-alone  system  or  in  a  multiple  workstation  distributed  network.  The 
system  can  maintain  multiple  configurations  from  which  the  user  can  select.  In  large  measure,  a  configuration  is  defined 
through  the  system’s  user  interface  and  is  stored  in  the  system’s  data  base  to  be  recalled  by  the  user  at  any  time. 

Three  operational  systems  are  currently  in  use.  These  systems  are  located  at  Hill  AFB  in  Ogden,  UT,  Kelly  AFB  in 
San  Antonio,  TX,  and  the  Phillips  Laboratory  at  Edwards  AFB  in  California.  Each  of  these  systems  is  configured  to  process 
X-ray  computed  tomography,  CT,  images.  The  Hill  AFB  installation  supports  the  aging  surveillance  effort  on  Minuteman 
third  stage  rocket  motors.  The  Kelly  AFB  system  supports  the  acceptance  inspection  of  airframe  and  engine  components  and 
torpedo  housing  components.  The  installation  at  Edwards  AFB  provides  technical  support  to  the  other  two  locations. 

This  paper  presents  the  development  history,  the  system  design  issues,  the  system  hardware  and  software 
architecture,  and  a  brief  description  of  the  operational  systems  and  their  functions. 

Keywords:  automated  NDE  processing,  NDE,  aging,  solid  rocket  motors,  computed  tomography 

1,  INTRODUCTION 


The  Air  Force  has  invested  significantly  in  inspection  technology  in  the  past  20  years.  The  investment  supporting 
the  rocket  propulsion  mission  has  been  mainly  in  the  implementation  or  development  of  data  acquisition  technology.  Work 
sponsored  by  the  Air  Force’s  Titan  launch  system  program  office  and  the  Air  Force  Wright  Laboratories  represent  two 
examples.  The  Titan  program  developed  X-ray  and  ultrasonics  facilities  to  perform  real  time  radiography,  RTR,  and  thru- 
transmission  and  pulse  echo  ultrasonics  inspections  on  the  new  Titan  IV  solid  rocket  booster.  The  Air  Force  Wright 
Laboratories  developed  large  industrial  CT  system  technologies  for  inspecting  ballistic  missiles.  These  CT  based 
technologies  have  subsequently  been  implemented  at  Hill  AFB,  UT  in  the  form  of  a  nine  million  electron  volt,  Mev,  facility 
for  inspecting  the  Minuteman  third  stage  motors  and  a  fifteen  Mev  facility  for  inspecting  all  Peacekeeper  stages  and  stages 
one  and  two  for  Minuteman.  Although,  some  data  processing  technology  was  also  implemented  with  all  of  the  data 
acquisition  technology  development,  the  assessment  of  the  components  being  inspected  is  still  based  on  visual  interpretation 
of  the  NDE  data. 

A  joint  R&D  effort  between  NASA  and  the  Air  Force  was  undertaken  in  1989  to  develop  a  new  generation  of  launch 
vehicles.  This  effort  was  called  the  Advanced  Launch  System,  ALS,  later  renamed  the  National  Launch  System,  NLS.  The 
goal  was  to  reduce  the  cost  of  placing  a  payload  in  low  earth  orbit  by  an  order  of  magnitude,  to  $300  per  pound.  The 
Strategic  Defense  Initiative,  SDI,  was  the  primary  driving  force  for  reducing  the  launch  costs,  although,  the  commercial 
launch  industry  was  also  a  factor.  The  tonnage  of  hardware  projected  to  be  placed  in  orbit  to  implement  a  spaced  based 
defense  is  extremely  large  and  the  cost  to  put  it  in  orbit  is  staggering.  Thus,  the  country  engaged  in  an  effort  to  provide 
cheaper  access  to  space.  The  Air  Force  managed  a  technology  program  for  ALS  named  NDE  for  Solid  Rocket  Boosters 
(NDE  for  SRB’s).  This  program  addressed  technology  to  reduce  the  fabrication  costs  of  solid  rocket  boosters  as  a 
contribution  to  the  goal  for  total  launch  costs.  The  goal  of  the  program  was  to  totally  automate  the  NDE  data  processing  and 
decision  processing  for  the  in-process  and  end  item  acceptance  during  the  manufacture  of  the  solid  rocket  boosters  for  the 
ALS  effort. 
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2,  PROJECT  HISTORY 


The  NDE  for  Solid  Rocket  Boosters  program  was  conceived  as  a  $12M  effort  consisting  of  four  phases  spanning 
five  years  The  program  was  to  conclude  with  the  delivery  of  a  production  ready  system  to  support  the  fabrication  of  the  solid 
rocket  booster  design  being  developed  in  other  ALS  projects.  The  tasks  in  the  first  phase  of  the  program  were  to  develop  the 
operational  requirements,  develop  the  functional  design  of  the  automated  system,  to  generate  a  hardware  and  software 
architecture  to  be  incrementally  developed  in  the  subsequent  three  phases,  and  to  define  the  test  and  validation  plan  to 
demonstrate  that  the  system  performed  properly.  The  automated  system  was  called  the  Automated  NDE  Data  Evasion 
System,  or  ANDES.  Although  it  was  to  be  developed  for  ALS,  from  the  program’s  beginning,  the  plan  was  to  build  ANDES 

as  generic  and  as  flexible  as  possible. 

It  is  not  unusual  for  a  large  government  program  to  be  initiated  with  significant  sums  of  money,  a  l^ge  amount  of 
fanfare,  and  great  expectations  only  to  be  significantly  reduced  in  scope  or  canceled  in  a  relatively  short  period  of  time.  This 
is  what  happened  with  the  ALS  effort.  Due  to  changes  is  the  strategic  arms  arena,  the  SDI  payload  requirements  were  greatly 
reduced  and  consequently  the  need  for  a  heavy  lift  launch  vehicle  at  that  time.  This  in  turn  eliminated  the  mam  thrust  e  mg 
the  requirement  for  ALS.  In  the  second  year,  the  ALS  funding  was  cut  dramatically.  In  the  third  year,  most  of  the  ALS 
pro^T-ams  were  ended.  The  NDE  for  SRB’s  effort  was  early  in  phase  two,  finalizing  the  system  design  and  beginning  to  wite 
software  The  program  was  reorganized  to  deliver  a  functioning  prototype  system  on  the  remaining  contract  funds.  While 
preparing  to  end  the  effort,  the  Air  Force  searched  for  other  benefactors  to  continue  the  development.  Two  were  found,  Kelly 
AFB  and  Hill  APB. 

A  new  task  in  the  NDE  for  SRB’s  contract  was  added  in  the  third  quarter  of  FY  91.  This  task  was  to  deliver  an 
operational  version  of  ANDES  to  Kelly  AFB  to  process  CT  images  for  several  miscellaneous  components  they  were 
fabricating-  or  refurbishing.  In  the  third  quarter  of  FY  92  another  task  was  added  to  develop  an  ANDES  system  to  support  the 
processing  of  CT  images  on  Minuteman  third  stage  solid  rocket  motors  at  Hill  AFB.  These  added  tasks  permitted  the 
program  to  extend  the  development  of  ANDES  into  operational  systems.  These  two  systems  do  not  have  all  of  the  functional 
capabilities  intended  in  the  original  ALS  design  and  described  in  this  paper.  They  do  contain  the  fundamental  operational 
capabilities,  plus  the  software  and  hardware  architecture  for  the  original  system  design  which  can  be  implemented  in  the 
future. 

3.  DESIGN  ISSUES 

Prior  to  describing  the  architecture  of  the  ANDES  system,  it  is  necessary  to  develop  some  background  information 
about  the  configuration  of  a  typical  solid  rocket  motor  (SRM)  and  the  fabrication  process  used  to  construct  a  motor.  This 
information  in  necessary  to  understand  why  the  software  and  hardware  are  organized  as  they  are.  Figure  1  is  a  drawing  of  a 


Figure  1.  Basic  Solid  Rocket  Motor. 


basic  solid  rocket  motor.  The  prominent  features  of  a  typical  SRM  are  the  motor  case,  propellant  grain,  nozzle,  and  ignitor. 
The  motor  case  may  be  a  welded  metal  construction  or  a  filament  wound  composite.  The  case  consists  of  a  cylindrical  barrel 
section  closed  at  each  end  with  curved  domes.  The  ignitor  and  nozzle  are  attached  to  the  forward  dome  and  aft  dome 
respectively.  In  the  case  of  a  composite  wound  case,  the  attachments  are  circular  metal  bosses.  On  the  inside  surface  of  the 
motor  case  are  two  other  components,  the  insulator  and  liner,  see  figure  2.  The  thicknesses  of  these  two  components  and  the 


case  are  exaggerated  in  the  figure.  The  insulation  is  a  rubberized  material  which  protects  the  case  from  the  heat  of  the 
burning  propellant.  The  liner  is  an  adhesive  interface  to  bond  the  rubber  based  propellant  to  the  insulation.  The  size  of  a 
solid  rocket  motor  varies  greatly.  The  diameter  of  SRM’s  can  range  from  a  few  inches  to  several  feet.  For  ALS,  the  case 
diameter  was  to  be  about  ten  feet  with  a  length  exceeding  80  feet.  Figure  2  also  indicates  the  three  major  categories  of  defects 
which  are  critical  in  SRM’s. 

The  fabrication  of  a  SRM  is  a  multi-step  process,  see  figure  3.  The  significant  features  in  this  diagram  of  the  process 
are  that  there  are  a  number  of  intermediate  process  completion  points,  that  NDE  may  be  performed  at  any  or  all  of  these 
points,  and  the  locations  of  the  various  process  steps  and  NDE  data  acquisition  are  likely  to  be  separated  by  significant 
distances  (miles).  The  NDE  data  collected  at  the  intermediate  process  steps  are  used  to  accept  the  part  for  further  processing. 
This  data  can  also  be  used  to  extract  process  control  information,  single  part  fabrication  history  information,  and  system 
production  history  information.  Typically,  this  information  data  base  is  in  the  form  of  a  logbook  which  follows  each  motor 
through  the  process.  In  addition  to  the  process  steps  described  in  figure  3,  there  are  other  functions  which  are  typical  to  the 
fabrication  process.  These  functions  include  program  administration,  scheduling  of  the  flow  of  the  components  through  the 
fabrication  and  inspection  processes,  planned  engineering  reviews  of  each  component,  and  material  review  board  (MRB) 
actions  on  components  which  experience  difficulties  or  develop  anomalies  during  processing. 

4.  ANDES  DESIGN  AND  DEVELOPMENT 

The  challenge  for  the  NDE  for  SRB’s  program  was  to  design  and  develop  an  automated  system  which  would  service 
all  of  the  fabrication  processes  and  functions  and  to  capture  the  knowledge  base  of  the  inspector  to  accurately  evaluate  the 
NDE  data  and  to  render  the  correct  judgements  on  the  acceptability  of  the  component.  It  was  also  desired  to  make  the 
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Figure  3.  Process  Steps  for  Fabrication  of  Solid  Rocket  Motors. 

resulting  system  as  paperless  as  possible.  This  would  reduce  cost  and  reduce  the  risk  of  losing  program  documentation.  One 
of  the  iTOst  formidable  tasks  was  to  define  what  the  various  production  and  inspection  personnel  did,  how  they  did  it,  what 
information  they  needed,  where  the  information  came  from,  what  information  they  generated,  and  to  whom  or  where  they 
reported  it. 

4.1  System  functional  description 

Figure  4  shows  a  top  level  functional  diagram  of  the  ANDES  system  as  it  was  designed  for  ALS.  The  two  ovals 
represent  the  two  major  software  modules,  the  seven  cylinders  represent  various  classes  of  information  to  be  stored  in  the 
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Figure  4.  Functional  Diagram  of  ANDES  Software. 


system  data  base,  and  the  computer  terminals  represent  three  of  the  user  interfaces  with  the  system.  The  arrows  de^ct  the 
directions  of  information  flow.  The  Inspection  System  module  is  the  interface  to  a  NDE  data  acquisition  system.  This  figure 
shows  only  one  of  these  modules,  however,  ANDES  is  designed  to  service  multiple  acquisition  systems.  The  actual  system 
would  have  a  tailored  Inspection  System  module  for  each  acquisition  system  that  is  connected.  What  is  not  apparent  from  this 
figure  is  how  the  software  system  is  configured  and  managed  from  a  global  standpoint.  The  mam  user  interface  for  setup, 
maintenance,  and  overall  system  management  is  implemented  as  part  of  the  Process  /  Product  Analysis  module.  The  software 
architecture  and  functionality  will  be  discussed  in  more  detail  later  in  the  paper. 


In  fi<^ure  4,  the  arrow  from  the  Inspection  System  oval  to  the  Process  /  Product  Analysis  oval  is  labeled  with  two 
types  of  data, "defect  tokens  and  raw  data.  Raw  data  is  the  NDE  data  generated  by  the  acquisition  system  and  defect  tokens 
are  small  packets  of  text  information  which  describe  the  characteristics  of  a  detected  feature,  see  figure  5.  The  approac  o 
“tokenizing”  the  information  about  a  detected  feature  was  chosen  to  minimize  the  amount  of  data  being  permanently  stored 

and  shared  between  processes. 


Token: 

{ 

class:  propellant 
radial__center:  151.019318 
angular_center:  153.066589 
.major_extent_mm:  9.614274 
maj  or_extent_deg:  3 . 1 67 1 5  2 
minor_extent_mm:  6.342917 
radiaLextent:  4.267532 
orientation:  85.215927 
area:  36.944504 
rel_amplitude:  0.874997 
min__dist_to_bore:  0.154984 
max_dist_to_bore:  4.422516 
min_dist_to_ins:  128.180756 
max_dist_to_ins:  133.870804 


Typed  Anomaly: 

2:  gouge  -  accept.  PSC  Script  used:  3RDG.gouge.any  (New) 
angle  center:  153.07  deg.;  major  extent:  9.61  mm; 

radial  center:  15 1 .02  mm;  radial  extent:  4.27  mm; 

minor  extent:  6.34  mm;  major  extent:  3.17  deg.; 

area:  36.94  sq.  mm;  relative  amplitude:  0.87  %; 

min.  distance  to  bore:  0.15  mm;  max.  distance  to  bore:  4.42  mm; 
min.  distance  to  ins.:  128.18  mm;  max.  distance  to  ins.:  133.87 


mm; 

axial  start: 


57.15  mm;  axial  extent: 


6.35  mm; 


Figure  5.  Example  Token  (left)  and  Corresponding  Typed  Anomaly  (right). 


4.2  Hardware  architecture 

The  hardware  architecture  used  for  the  ANDES  system  was  chosen  primarily  due  to  the  operational  requirements 
dictated  by  the  fabrication  process  layout,  several  locations  widely  separated  in  distance.  The  architecture  is  shown  in  figure 
6.  The  existence  of  several  stations  in  the  process  flow  which  can  be  widely  separated  required  a  system  with  several 
workstations  connected  on  a  local  area  network.  The  figure  depicts  two  inspection  facilities  and,  consequently,  two 
inspection  system  modules.  The  figure  also  shows  one  workstation  for  the  rest  of  the  activities,  but  this  would  most  probably 
be  several  stations.  For  example,  a  work  station  would  be  located  at  the  program  office  to  initiate  and  monitor  the  progress  of 
component  fabrication.  Another  workstation  would  be  located  in  each  of  the  engineering  areas,  process  control,  NDE,  and 
analysis.  The  data  storage  and  data  processing  would  be  distributed  between  the  various  workstations. 

4.3  IS  software  architecture 


Now  that  an  overview  of  the  hardware  and  software  architectures  has  been  presented,  a  more  detailed  discussion 
about  how  ANDES  works  and  what  it  does  is  in  order.  Let  us  turn  our  attention  to  the  inspection  sysitm  (IS)  module  first. 
Figure  7  shows  a  detailed  functional  diagram  of  the  interior  processes  of  this  module  as  it  was  originally  designed.  The  top 
three  boxes  in  the  figure  represent  the  software  features  which  would  handle  the  internal  functions  for  communicating  with  the 
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Figure  6.  ANDES  Hardware  Architecture. 
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Figure  7.  Functional  Diagram  of  Inspection  System  Module. 


rest  of  the  ANDES  system.  The  Control  and  Dispatch  Module  in  the  IS  is  the  inspection  system  operator  s  interface  for 
managing  and  scheduling  the  IS  processes  and  for  responding  to  system  messages  and  requests.  The  Acquisition  Module  is 
the  interface  with  the  data  acquisition  system  for  the  IS.  The  Processing  Module  is  responsible  for  performing  t  e  image 
analysis  and  feature  extraction  from  the  NDE  data.  The  Raw  Data  Storage  is  the  location  of  the  NDE  data  files  generated  by 

the  acquisition  system. 

Looking  at  an  operational  scenario  is  the  best  way  to  clarify  the  functioning  of  the  IS  module.  The  production 
manac^er  issues  a  message  to  the  ANDES  system  requesting  the  normal  thru-transmission  ultrasonic  inspection  on  motor  senal 
number  A-005  which  is  being  transported  to  the  ultrasonic  facility.  This  motor  has  completed  the  case  insulation  processing 
step  (see  figure  3)  and  needs  to  be  checked  for  unbonds  between  the  insulation  and  case.  The  ANDES  system  relays  the 
message  to  the  appropriate  Inspection  System  Module  which  places  the  request  in  the  request  queue,  informing  the  operator 
of  an  inspection  request.  When  the  motor  arrives,  the  operator  mounts  it  in  the  inspection  system  and  initiates  thru- 
transmission  data  acquisition.  When  data  acquisition  is  completed  the  data  is  stored  in  Raw  Data  Storage.  The  operator  then 
issues  a  command  to  the  IS  to  initiate  data  processing  using  the  normal  thru-transmission  processing  template.  This  template 
controls  the  actions  of  the  Processing  Module  for  retrieval  of  the  raw  data,  feature  extraction,  token  generation,  and 
transmission  of  any  token  information  generated  to  the  ANDES  data  base.  The  IS  module  also  issues  two  messages  of  its 
own.  One  goes  to  the  originator  of  the  data  request  informing  him  that  the  action  is  complete  and  the  other  goes  to  the 
decision  system  module  of  ANDES  informing  it  that  there  is  a  set  of  anomaly  tokens  to  be  processed. 

It  was  envisioned  that  a  fully  functional  ANDES  system  would  be  integrated  closely  enough  with  the  data  acquisition 
systems,  through  the  respective  IS,  that  adaptive  scan  features  would  be  available.  This  would  mean  that  if  the  decision 
system  modules  of  ANDES  detected  problems  with  the  data  or  if  there  were  difficulty  processing  anomalies  from  the  token 
information,  a  request  for  a  non-standard  inspection  could  be  issued  automatically  to  the  IS.  This  inspection  request  would 
contain  the  specifics  of  the  inspection  procedure  to  gather  the  additional  data  needed  in  order  to  properly  assess  the  part.  This 
request  would  be  examined  by  the  inspection  system  operator  and  he  could  either  perform  the  requested  operation  or  consult 
with  the  production  manager  to  deny  the  request  and  instruct  ANDES  to  use  the  existing  data. 

4.4  PPA  software  architecture 

The  largest  module  of  the  ANDES  system  is  the  Process  /  Product  Analysis  (PPA)  module.  This  module  controls  the 
main  user  interface  for  the  system.  The  system  management  functions  and  much  of  the  system  setup  and  tailoring  are 
performed  through  this  module.  In  addition,  the  PPA  module  performs  the  analysis  and  decision  rendering  functions  on  the 
tokens  passed  from  the  IS  module.  The  functional  diagram  of  the  analysis  and  decision  processes  is  shown  in  figure  8. 

The  PPA  module  periodically  polls  the  message  area  of  the  ANDES  data  base  for  a  message  that  a  list  of  tokens  has 
been  generated  by  an  IS  module.  When  this  message  is  detected,  PPA  retrieves  the  list  of  tokens  and  proceeds  to  process 
them  using  a  template  which  has  been  designated  by  the  operator.  As  shown  in  the  figure,  the  image  and  token  data  are 
received  from  the  IS  module.  The  image  data  would  then  be  checked  to  verify  the  quality  of  the  data.  If  the  quality  was 
sufficiently  low,  the  PPA  could  issue  a  message  to  the  IS  requesting  the  data  be  replaced  or  permission  to  proceed  with 
substandard  quality.  The  token  data  describing  each  anomaly  or  feature  in  the  NDE  data  would  proceed  to  the  Typer.  In  this 
step  the  token  data  is  classified  by  type,  size,  orientation  and  location,  see  the  example  in  figure  5.  Once  typed,  the  tokens  are 
passed  to  the  specification  comparator  which  checks  each  anomaly  against  the  appropriate  product  specification  criteria.  In 
this  step  each  anomaly  is  categorized  as  being  within  or  outside  of  tolerances.  No  further  processing  would  be  done  on  those 
anomalies  that  are  within  tolerances.  They  would  simply  be  stored  and  reported.  Anomalies  exceeding  the  tolerances  would 
be  tagged  as  rejectable  defects  and  would  then  be  subjected  to  engineering  analysis  procedures  built  inte  the  PPA  module  to 
estimate  the  remaining  margin  of  safety  and  the  projected  impact  on  performance  of  the  part.  All  of  this  information  would 
then  be  passed  to  the  final  decision  module  to  issue  the  recommended  disposition  of  the  part,  accept  or  reject.  If  required,  the 
system  would  then  assemble  a  material  review  board  report  to  support  the  MRB  process  that  would  decide  if  the  part  could 
still  be  used  with  the  lower  margin  of  safety,  if  the  part  can  be  repaired,  or  if  the  part  must  be  scrapped. 

The  data  processing  step  which  compares  the  typed  anomaly  information  to  product  specifications  is  performed  at 
three  different  levels.  The  first  level  is  the  single  anomaly  check.  At  this  level  each  reported  anomaly  is  checked  against 
specifications  for  a  single  anomaly  of  the  appropriate  type.  For  example,  if  a  void  less  than  one  half  inch  in  diameter  is 
acceptable,  then  any  single  void  smaller  than  this  is  marked  acceptable  and  the  system  proceeds  to  the  next  anomaly.  Once  all 
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Figure  8.  Analysis  and  Decision  System  Functional  Diagram. 

individual  anomalies  have  been  checked,  the  system  then  uses  a  nearest  neighbor  criteria  to  consider  combined  anomaly 
effects.  In  this  check,  the  system  is  instructed  that  anomalies  of  similar  type  which  fall  within  some  threshold  distance  of  one 
another  are  to  be  considered  as  a  combined,  larger  anomaly.  This  combined  anomaly  condition  is  then  checked  against  the 
established  criteria.  If  the  inspection  data  is  two  dimensional  in  form,  such  as  an  ultrasonics  C-scan,  the  anomaly  processing 
is  now  complete.  If  the  data  is  three  dimensional  in  nature,  such  as  contiguous  CT  images,  a  third  level  of  processing  is  used. 
For  the  case  of  CT  images,  the  first  two  processing  levels  are  performed  on  each  CT  image  or  slice.  Once  all  slices  have  been 
processed  individually,  the  system  checks  each  anomaly  in  a  slice  for  an  adjoining  anomaly  in  the  next  contiguous  slice.  In 
this  manner  anomalies  which  span  several  slices  are  identified  and  treated  as  a  single  anomaly.  The  slice  spanning  anomaly  is 
then  compared  to  the  appropriate  criteria  to  test  for  acceptability. 

While  the  ANDES  system  was  being  designed,  it  was  recognized  that  the  decisions  rendered  by  this  automated 
system  would  be  significant  in  terms  of  affects  on  production  schedules  and  funds,  especially  if  the  system  recommended  that 
a  fully  processed  solid  rocket  booster  be  rejected.  Therefore,  it  was  very  important  that  the  decisions  the  system  made  could 
be  traced  and  verified.  Two  methods  were  designed  to  provide  this  verification  process.  The  first  method  was  the  institution 
of  an  audit  trail  of  the  anomaly  processing.  The  user  can  display  the  acceptance  criteria  for  any  of  the  reported  anomalies  and 
the  system  will  insert  the  corresponding  values  from  the  anomaly.  In  this  way  the  user  can  determine  which  criteria  controlled 
the  accept  /  reject  decision  for  the  anomaly  and  what  the  actual  value  was  of  the  anomaly  characteristic  which  generated  the 
decision.  The  second  method,  which  was  designed  but  not  fully  developed,  is  a  data  simulation  module.  This  module  would 
allow  the  operator  to  develop  a  realistic  set  of  data  containing  anomalies  using  segments  of  actual  data.  In  this  way,  the 
simulated  data  contained  the  characteristics  of  real  data.  The  synthesized  data  sets  with  the  user  prescribed  anomalies  would 
then  be  fed  to  the  ANDES  system  and  processed.  The  results  could  then  be  compared  to  the  known  characteristics  of  the  data 
to  determine  how  the  ANDES  system  was  functioning. 


5.  TAILORABILITY 


It  has  been  stated  that  the  ANDES  system  was  designed  to  be  as  generic  and  flexible  as  possible.  The  purpose  was 
to  create  a  system  which  could  be  applied  to  as  broad  a  scope  of  products  and  processes  as  possible  and  to  minimize  the  cost 
of  tailoring  the  system  to  a  specific  application.  The  advantages  of  doing  this  are  rather  obvious,  being  the  reduction  of  time 
and  cost  to  reconfigure  the  system  for  a  new  project  at  an  existing  site  or  the  establishment  of  an  ANDES  system  at  a  new  site. 
The  system  was  also  designed  to  maintain  several  different  processing  configurations  and  allow  the  operator  to  select  the 
configuration  to  be  used  from  a  menu.  This  capability  would  allow  a  single  .^DES  installation  to  service  multiple 
production  programs  which  use  the  same  facilities  for  fabrication  and  inspection. 

The  core  processes  of  the  ANDES  system  are  totally  generic.  These  processes  include  the  data  base  management 
system,  the  communication  and  messaging  system,  and  the  data  analysis  and  decision  processing  engine.  It  is  the  penpheral 
processes  and  data  handling  which  are  unique  to  each  application.  The  parts  of  the  system  which  are  unique  include  the 
interface  to  the  individual  data  acquisition  systems,  the  image  analysis  process  which  extacts  the  features  from  the  NDE  data, 
the  specific  anomalies  and  defects  which  are  applicable  to  the  inspected  object,  the  specifications  for  the  appropriate 
anomalies,  and  the  contents  of  displayed  or  printed  reports  from  ANDES. 

Earlier  it  was  stated  that  the  IS  module  was  the  least  generic.  This  is  because  this  module  must  interface  with  the 
data  acquisition’system.  Even  so,  a  substantial  part  of  the  IS  is  common  code.  In  figure  7,  the  communication  module  and 
message  queues  would  not  change.  The  control  and  dispatch  module  may  or  may  not  require  modification.  However,  the 
acquisition  module  and  the  processing  module  perform  unique  processes  depending  upon  the  data  acquisition  system  and  the 
type  of  image  data  being  processed.  They  would  need  to  be  modified  to  incorporate  the  specifics  for  the  acquisition  system 
and  the  data^,  The  acquisition  module  is  the  interface  between  ANDES  and  the  data  acquisition  system.  The  primary  function 
of  this  module  is  to  retrieve  the  inspection  data  file  or  files  from  the  acquisition  system,  convert  the  format  to  the  internal 
format  that  ANDES  uses,  and  store  the  data  in  raw  data  storage.  The  processing  module  in  figure  7,  performs  the  image 
processing  and  extracts  features  which  could  be  anomalies  from  the  image  data.  The  image  processing  steps  are  unique  to  the 
type  of  data  being  processed,  ultrasonics  versus  CT,  or  the  modality  of  the  data,  amplitude  versus  time  of  flight.  The  feature 
extraction  processing  is  also  unique  since  it  depends  not  only  on  the  type  of  data  to  be  processed,  but  also  on  the  features  of 
interest  which,  themselves,  depend  upon  the  component  being  inspected. 

The  image  processing  function  was  somewhat  generalized  by  using  an  image  processing  system  which  executes  user 
definable  networks  of  standard  and  custom  data  processing  modules.  The  overall  ANDES  configuration  file  contains  the 
name  of  the  image  processing  procedure  to  be  used  and  the  PPA  passes  this  name  to  the  IS  when  the  request  for  data  is  issued. 
When  the  NDE  data  from  the  acquisition  system  is  available,  the  IS  issues  the  command  to  the  image  processing  system  to 
execute  the  procedure  name  received  from  the  PPA.  The  image  processing  procedure  contains  the  details  about  which  image 
processing  modules  to  use,  in  what  order,  what  the  input  parameters  are  for  the  modules,  and  any  other  unique  data  that  is 
required.  This  arrangement  eliminates  the  need  to  make  hard  code  changes  in  the  main  execution  stream  of  the  IS  module  to 
implement  changes  in  the  image  processing.  Any  image  processing  code  which  must  be  written  and  compiled  is  limited  to 
writing  custom  modules  for  networks  executed  by  the  image  processing  system.  The  networks  themselves  are  generated  using 
an  interactive  interface  in  the  image  processing  system.  Using  this  interface,  assemblages  of  standard  and  custom  modules 
can  be  hooked  together  to  perform  the  necessary  functions  without  modifying  the  IS  or  other  ANDES  system  software. 

Very  few  modifications  to  compiled  code  would  be  required  in  the  analysis  and  decision  system  (see  figure  8)  to 
tailor  the  operation  for  a  new  application.  The  data  quality  analyzer  module  would  require  code  modification  since  the  data 
from  the  inspection  system  will  change  with  the  application.  The  typer,  specification  comparator,  and  operational  criticality 
analyzer  are  all  script  driven.  Once  the  processing  has  reached  the  accept  /  reject  decision  processor,  the  data  has  evolved 
into  a  standard  content  so  this  module  would  not  require  modification.  The  reports  for  an  individual  application  are  likely  to 
be  somewhat  unique.  The  modifications  to  the  report  generation  function  could  be  either  hard  coded  or  generated  through  the 
report  interface  of  the  data  base  management  system,  depending  on  the  specific  requirements.  ANDES  employs  a  script 
language  interpreter  to  control  and  execute  most  of  the  processes  in  the  analysis  and  decision  system  loop.  The  scripting 
language  is  patterned  after  the  method  described  in  the  ADA  Language  Reference  Manual,  ANSI/MIL-STD-1815A-1983. 
This  approach  is  very  much  like  an  interpreted  BASIC  language  for  desk  top  computers.  Using  the  ANDES  script  editor 
window,  the  user  writes  text  files  which  define  the  processing  to  be  done.  Parameter  values  describing  the  detected  anomalies 
are  retrieved  from  the  anomaly  tokens  and  processed  by  the  script.  The  script  then  exports  the  results  in  the  form  of 
parameter  values  which  are  stored  in  the  data  base  for  use  by  subsequent  processes.  The  script  can  also  initiate  the  execution 


of  external  programs,  if  needed,  and  retrieve  results  from  the  program  when  it  is  finished. 

An  example  of  a  script  is  shown  in  figure  9.  This  script  would  be  executed  by  the  typer  function  to  determine  the 
type  of  a  detected  anomaly.  The  characteristics  used  by  the  typer  script  are  stored  in  the  token  information  for  the  anomaly. 

In  the  script  shown  in  figure  9  there  are  ten  input  parameters  which  are  retrieved  from  the  token.  These  parameters  are 
defined  between  the  statements  “extemal_variables:”  and  “end_external_variables;”.  These  parameters  consist  of  one  text 
string  and  nine  numbers.  The  purpose  of  the  script  is  to  establish  the  type  of  the  anomaly  so  the  only  output  value  is  a  text 
string  called  “type”.  The  main  part  of  the  script  is  a  series  of  if-then-else  logic  statements  which  lead  to  various  value  for  the 
anomaly  type  depending  on  the  values  of  the  input  parameters.  Similar  scripts  are  used  by  the  specification  comparator  and 
the  operational  criticality  analyzer. 

The  remainder  of  the  tailoring  functions  is  accomplished  through  various  user  dialog  windows  in  the  main  ANDES 
user  interface.  These  function  include  some  which  are  rather  mundane,  such  as  establishing  labels  to  identify  various  aspects 
of  the  configuration  to  the  user.  Other  functions  are  used  to  establish  parameters  required  for  the  operation  of  the  system  and 
to  define  proceedures  to  be  followed.  The  allowable  names  for  the  anomaly  types  and  the  allowable  names  for  characteristics 
used  to  describe  an  anomaly  are  defined  from  the  main  user  interface.  These  names  become  the  only  valid  names  recognized 
by  ANDES  and  are  used  in  all  data  processing  procedures.  This  enforces  consistancy  in  terminology.  The  token  correlation 
and  nearest  neighbor  processing  for  anomalies  may  be  either  script  driven  or  handled  by  built  in  parameterized  procedures. 
The  method  of  choice  for  these  functions  is  selected  from  the  user  interface.  Finally,  the  product  specification  criteria  for  all 
anomalies  may  be  specified  as  a  function  of  geometry  zones  in  the  component.  These  zones  are  defined  through  the  user 
interface.  All  of  these  definitions  are  saved  in  the  system  data  base  under  a  unique  configuration  name  and  can  be  used  or 
modified  by  the  user  at  any  time.  ANDES  can  operate  only  one  configuration  at  a  time,  but  a  number  of  different 
configurations  can  be  stored  in  the  data  base  and  the  user  can  select  the  one  he  wishes  to  use  from  the  list. 

6.  OPERATIONAL  INSTALLATIONS 

There  are  three  functional  ANDES  sites.  Two  of  these  are  operational  sites,  one  at  Kelly  AFB,  San  Antonio,  TX  and 
the  other  at  Hill  AFB,  Ogden,  UT.  The  third  site  is  located  at  the  Air  Force  Phillips  Laboratory  facility  at  Edwards  AFB, 
Edwards,  CA.  The  Phillips  Lab  is  responsible  for  the  user  support  of  the  operational  systems,  so  the  system  at  Edwards  is 
used  for  system  support  and  development.  Both  operational  sites  have  performed  very  well.  The  system  installed  at  Kelly 
AFB  has  been  operational  since  15  June,  1993  and  there  have  been  no  problems  reported.  The  system  at  Hill  AFB  has  been 
on-line  since  15  December,  1994.  One  minor  software  problem  was  discovered  and  has  been  eliminated.  Several  other 
problems  have  been  reported,  but  all  have  been  traced  to  inconsistences  or  problems  with  the  data  files  from  the  data 
acquisition  system. 

The  Kelly  AFB  system  was  tailored  to  process  three  different  components,  see  figure  10.  The  yoke  and  torpedo 
housing  were  metal  castings  which  had  to  be  inspected  for  anomalies  such  as  void  content,  cracks,  and  inclusions.  The 
scavenge  tube  was  inspected  for  leak  paths  and  total  brazed  area  between  the  end  of  the  tube  and  the  fitting.  The  Hill  AFB 
system  provides  supporting  data  and  documentation  to  the  official  film  X-ray  acceptance  procedures  for  new  third  stage 
motors.  The  system  is  also  used  to  assess  motors  which  are  cycled  back  through  Hill  AFB  for  maintenance  after  deployment. 
The  motors  are  inspected  for  cracks,  voids,  and  debonds. 

7.  SUMMARY 

The  work  begun  on  the  ALS  project  has  resulted  in  the  development  of  an  operational  system  (ANDES)  which  can 
automatically  process  digital  NDE  data  and  provide  a  recommended  disposition  to  either  accept  or  reject  the  component. 

Two  operational  systems  have  been  in  service  for  over  a  year  and  the  performance  to  date  has  been  very  good.  The  ANDES 
system  is  generic  in  that  it  can  process  literally  any  inspection  data  on  any  component  with  very  few  constraints. 


external  variables: 
in_text:  class; 

in_number;  rel_amplitude,  major_extent_nim,  niajor_extent_deg, 
minor_extent_mm,  axial_start,  min_dist_to_bore,  min_dist_to_ins, 
orientation; 

out_text:  type; 
end_external_variables; 

if  (rel_amplitude  >=  1.0)  then 
type  :="inclusion"; 

elsejf  (class  =  "rubber_case")  then 
if  ((axiaLstart  >=  1725)  and  (axial_start  <=  1743))  then 

type:=  "bossins/case  unbond";  //  boss  insulation/case  unbond 
else 

type  :=  "ins/case  unbond";  //  insulation/case  unbond 
end_if; 

elsejf  (class  =  "propellant")  then 
if  ((major_extent_mm  >  3)  and 

((major_extent_mm  /  minor_extent_mm)  >=  2.0))  then 
if  (rel_amplitude  >=  0.65)  then 
type  :=  "liner  wipe"; 

elsejf  (((orientation  >  80)  or  (orientation  <  -80))  and  //  parallel 
(min_distjoJns  <=  5))  then 
type  :=  "tear"; 
else 

type  :=  "crack"; 
endjf 
else 

if  (inin_distJo_bore  <  1)  then 
type  :=  "gouge";  //  or  surface  void,  treated  the  same. 

else 

type  :=  "void"; 
endjf 
endjf; 


else 

type:=  "undetermined"; 
end  if 


Figure  9.  Excerpt  from  ANDES  Typer  Script. 


